Database
security is mainly about managing permissions. Permissions are the
security mechanisms that tie principals (for example, logins) to
securables (for example, tables). With SQL Server 2008, permissions can
be applied at a granular level that provides a great deal of
flexibility and control.
Permissions in SQL Server 2008 revolve around three commands: GRANT, REVOKE, and DENY.
These three commands were also used in SQL Server 2005 and SQL Server
2000. When permission is granted, the user or role is given permission
to perform an action, such as creating a table. The DENY statement denies permission on an object and prevents the principal from gaining GRANT permission based on membership in a group or role. The REVOKE statement removes a permission that was previously granted or denied.
When specifying permissions, you need to carefully consider the hierarchy that exists between GRANT, REVOKE, and DENY.
This is particularly important when the principal (for example, user or
login) is part of a group or role and permissions have been granted on
securables at different scopes of the security model. Following are
some examples of the precedence that exists between these statements:
A GRANT
of a permission removes any REVOKE or DENY on a securable. For example,
if a table has SELECT permission denied on it and then the SELECT
permission is granted, the DENY permission is then removed on that
table.
DENY and REVOKE remove any GRANT permission on a securable.
REVOKE removes any GRANT or DENY permission on a securable.
Permissions
denied at a higher scope in the security model override grants on that
permission at a lower scope. Keep in mind that the security model has
the server scope at the highest level, followed by database and schema.
So, if INSERT permission is denied on tables at the database level, and INSERT on a specific table in that database is granted at the schema level, the result is that INSERT is denied on all tables. In this example, a database-level DENYGRANT at the lower schema level. overrides any
Permissions granted at a higher scope in the security model are overridden by a DENY permission at a lower level. For example, if INSERT permission is granted on all tables at the database scope, and INSERT is denied on a specific table in the database (schema scope), INSERT is then denied on that specific table.
The assignment of a permission includes the GRANT, DENY, or REVOKE
statements plus the permission that these statements affect. The number
of available permissions increased in SQL Server 2005 and has been
carried forward to SQL Server 2008. Familiar permissions such as EXECUTE, INSERT, and SELECT
that were available in SQL Server 2000 are still around, plus the new
permissions that were added in SQL Server 2005. Following are some of
the new types that were added in SQL Server 2005:
CONTROL— This
type confers all defined permissions on the securable. This
ownership-like capability also cascades to any lower-level objects in
the security hierarchy.
ALTER—
This type confers the capability to change the securable’s properties
but does not include the capability to make ownership changes. If ALTER is applied on a scope such as a database or a schema, the capability to use ALTER, CREATE, or DROP on any object in the scope is allocated as well.
IMPERSONATE— This type allows the principal to impersonate another user or login.
VIEW DEFINITION—
This type allows access to SQL Server metadata. This type of data is
not granted by default in SQL Server 2008; therefore, the VIEW
DEFINITION permission was added to manage access.
The combination of
available permissions and the securables that they can be applied to is
extensive. The permissions that are applicable depend on the particular
securable. SQL Server Books Online lists the permissions for specific
securables. You can use the index feature at Books Online to look for
“permissions [SQL Server].”
You
can also view the available permissions by using system functions and
catalog views. The following example uses the sys.fn_builtin_permissions function to retrieve a partial listing of all the available permissions:
SELECT top 5 class_desc, permission_name, parent_class_desc
FROM sys.fn_builtin_permissions(default)
order by 1,2
/* Results from previous query
class_desc permission_name parent_class_desc
---------------- --------------- -----------------
APPLICATION ROLE ALTER DATABASE
APPLICATION ROLE CONTROL DATABASE
APPLICATION ROLE VIEW DEFINITION DATABASE
ASSEMBLY ALTER DATABASE
ASSEMBLY CONTROL DATABASE
*/
The granularity with
which permissions can be applied with SQL Server 2008 is impressive
and, to some degree, challenging. When you look at all the available
permissions, you will see that some planning is needed to manage them.
In the past, fixed database roles were simple to use but in many cases
provided permissions that went beyond what the user needed. Microsoft
has supplied the tools to facilitate the concept of “least privileges,”
which means providing only the privileges that are needed and nothing
more.
